1. Field of the Invention
This invention relates to the general field of computer security, in particular, to detection of unauthorized, altered or potentially malicious executable code.
2. Description of the Related Art
Terms such as “virus,” “worm,” “Trojan horse,” and “spyware” have entered the vocabulary of ordinary computer users, not to describe medical conditions or tales of classic warfare and espionage, but rather to describe weaknesses in software. Modern computer users are also often—too often—confronted with the need to update (“patch”) faulty software, often precisely in response to one of the above-mentioned weaknesses that a hacker might exploit. Even absent malicious activity, some software that is loaded into a computer is or becomes corrupted, meaning that it is no longer the same as what first was or should have been installed. In general, all of these problems stem from the presence of executable code that is not as it should be, or that should not be present in the computer at all.
In response, prudent computer users typically install other software to detect and remove malicious code such as viruses, worms, etc. Still other software tries to detect and repair “bugs” not only in installed programs, but often also in system-level code.
One problem with conventional methods for detecting and eliminating unwanted or faulty code is that they are typically reactive, meaning that they rely on up-to-date information identifying suspicious code. Such information often comes too late, however. For example, a virus may infect millions of computers before it is identified and analyzed and included in a data base of virus definitions, and even then users must know to download the new definitions, assuming this is even possible with the virus in their systems. Another problem is that such detection and repair software usually functions as a kind of “batch” process in that it operates on entire files at a time when these files are not being actively used or modified.
One other way that users try to protect their systems from infection by viruses or corruption of files is to isolate sensitive files (or memory regions) in some way that they cannot be accessed or modified except by trusted users or sub-systems. Isolation may be accomplished using all software or with hardware support. Isolation alone does nothing to detect and prevent malicious code from being executed if it has already somehow made it into the “safe” area, however. Moreover, a virus that jumps to and executes outside the protected memory region may be able to avoid detection.
One form of “isolation” that is becoming more widely considered involves hardware support in the form of access control bits, which prevent execution of code on a given page of memory. However, the access control bits alone do not guarantee that what is in the corresponding page is in fact safe. For one thing, if malicious code is found within the boot loader, or within certain components of the operating system, then it could affect the access control bits and thereby defeat what security they otherwise provide. Moreover, the contents of a page are no safer than they were when they were first downloaded, and are only as trustworthy as the original source, digitally signed or not. Even if such hardware-based security could be perfected, however, it would still not benefit users of other hardware architectures that do not provide access control bits.
A secure or “trusted” computing platform should guarantee that it executes only permissible code. For example, administrators of public (or corporate) computer terminals might want to restrict users to running only a pre-installed set of approved applications. On a smaller scale, parents might want to ensure that their home computers execute only applications they know to be appropriate for children.
A common way to increase the security of such “trusted” computing platforms is to employ cryptographic techniques to “attest” to the validity of code before executing it. The traditional approach of boot-time verification has been implemented in several commercially available products, including gaming platforms and some personal computers such as the IBM Thinkpad with the TCPA chip. This approach, while useful, does nothing to guarantee the validity of currently executing code. For instance, the user may have booted permissible software that is later compromised and hijacked to run other, non-permissible code. For example, Microsoft Corporation suffered great embarrassment when a hacker exploited a bug in the attested game “007: Agent Under Fire” running on Microsoft's “secure” Xbox gaming platform to cause it to load the Linux operating system.
A method for run-time verification is discussed in “A Virtual Machine Introspection Based Architecture for Intrusion Detection,” Tal Garfinkel and Mendel Rosenblum, The Proceedings of the Network and Distributed Systems Security Symposium (February 2003). Garfinkel and Rosenblum use virtualization software developed by VMware, Inc., of Palo Alto, Calif., to aid in the inspection of running code by periodically scanning the code section of programs loaded into memory and hashing to verify that the code has not been tampered or corrupted.
One weakness of this system by Garfinkel and Rosenblum is that it does not ensure that the code currently being executed, as opposed merely to being part of a loaded program, is safe. Whereas their system inspects the code segments of processes known to be running, a buffer overflow exploit (one of the most common attacks) will not modify the segment, but will simply jump to a new memory region and begin executing, completely bypassing the security provided by the system. Still another disadvantage of the disclosed system is that it requires support incorporated into the guest operating system to achieve this.
What is needed is therefore a system and a related method of operation that can verify the validity of currently executing code without requiring specific knowledge of what entity the code belongs to and that cannot be bypassed by a simple jump in memory. The new solution should preferably be useful on a variety of architectures, both those that have hardware support (such as access control bits) and those that do not. This invention provides such a new solution.